A recent development in computer system firmware is an extensible firmware interface (EFI) framework that allows software vendors to develop operating systems programs that can be used with a variety of central processing units (CPUs). An application binary interface (ABI) is included that specifies how to pass data on the stack for a given CPU type. By abstracting the platform, the framework provides many advantages over systems employing legacy architecture. As this concept of component architecture progresses, system architecture is emerging that uses ABIs and software abstraction throughout the entire system initialization process. This includes not only CPU initialization, but chipset and I/O device initialization as well. A software framework is provided that allows multiple parties to write small pieces of code that abstract how portions of the chip set or I/O complex work. Within such a framework, products from various vendors will interoperate. The pieces of code from each vendor are contained in initialization modules. During a system initialization phase (after CPU reset, but prior to memory initialization) core initialization code dispatches the initialization modules in a sequenced order to provide basic services. The initialization phase initializes enough of the system to enable follow-on phases, for example, the driver execution phase that is responsible for initialization processes that are algorithmically more complex such as scanning I/O busses, enumerating resources and installing drivers.
This concept of allowing contributions of drivers and applications from multiple parties raises several concerns. The security of system firmware, provided by a single vendor, is implicit from the vendor. The incorporation of code modules from various sources imperils system integrity as there is no provision to either sandbox or validate the code. The EFI platform executes in physical mode. Execution in physical mode means that all addresses correspond to actual memory locations. Although execution in physical mode provides the OS loaders with full access to all platform resources, it also precludes the use of virtual memory page tables and the protection they provide in the preboot. Since boot firmware has full machine access, sensitive data structure and code of the core EFI are subject to corruption through access by drivers and applications. Techniques, such as code signing, to validate the source of drivers and applications, cannot guarantee fault isolation when the system state has been corrupted by bad code.
Another difficulty is legacy code support. For many years software has been written to be compatible with the PC/AT platform. Many legacy operating systems and option ROMs require PC/AT memory-mapped hardware/software. This legacy code executes in Real Mode that limits the processor to 1 Mb of memory and provides no memory management or memory protection features.